Subject: Scalability comments

From: [email-masked] (Scott Barvick)
Date: Mon, 7 Aug 1995 10:39:16 -0400 (EDT)

My comments on the Scalability RIG activities to date...

In the effort to produce the right solution, I think it is important
to figure out what the problem is that we are trying to solve before
we pick at specifics of a proposed solution (e.g. Cisco's).  David 
suggests 3 main scaling problems which need to be addressed.  I agree
with his summarization and think that our first priority should be
to think about the needs of the central site.  If we don't
address this first, we will be missing the largest and earliest
requirement to provide further DLSw adoption.  Broadcasts and the peer
administration are the other major issues to we should target
in this RIG.  We haven't mentioned another scaling issue which is
the scalability of central site DLC termination.  We don't have much of a
choice here, but I think it is worth thinking about it.

>From my perspective, I have 3 main issues with the Cisco proposal
as a solution to "DLSw Scalability".

1) As we have stated, I think that the focus of Cisco's proposal is
to address the any-to-any broadcast problem.  This problem is important, but it
but it does not focus on the scalability issues of central site routers.
The proposal fits in more with the broadcast scaling problems of NetBIOS 
and to some degree of PU2.1 connectivity between branches.

2) About the proposal as it relates to solving the broadcast problems, 
I have a problem with "architecting" another component into the network 
because of the complexity and cost.  I disagree with David in that we can
look at the frame relay to the FEP as an alternative for DLSw scalability.  As
he says, we all have products that provide this capability, but DLSw needs
to solve the problem too because it will be the correct solution in many
cases.  However, DLSw cannot ignore the fact that there are competing 
solutions.  If DLSw does not solve the problem, or requires extra
boxes to do it, DLSw will not be chosen.  We may end up needing an 
extra boxes (relays, CDS, etc), but I would like to try to avoid it
before we jump in with an architecture that requires it.  We now have
tactical multiple hop DLSw networks to address scalability, but at least
the architecture doesn't yet require it.

3) I would like to attempt to find solutions which are less complex from
a management and problem resolution perspective. One of 
the reasons DLSw is doing so well is that it is conceptually very   
simple.  Defining another component moves us away from the simplicity 
that customers have come to expect.  The trick is that DLSw is not
simple, but we make it appear so to the customer by hiding all of the
difficulties and making it look "just like SRB".  I would like to strive
for simplicity/manageability as one of our goals.  

As a suggestion, I would like to reopen the discussion of dropping
to a single TCP session as a first step in our scalability solution.
Doubling the number of central site connections supported would go a long
way in our DLSw scalability efforts without requiring any significant
changes in code or concept.

Scott